Subject: Reg: IP AS-TO-AS Interface.

From: "Raghu V.V.J Vadapalli" <[email-masked]>
Date: Sun, 16 Aug 1998 14:51:18 -0700 (PDT)

Dear All..

I have a proposal for AS-TO-AS interface for supporting
QoS routing. It is some what similar to ATM pnni. The
proposal is not complete. If anybody wants the entire 
proposal of this I can send them a copy of the same with 
all the proposals. I think it will work out (hope so :):):))

It defers from ATM pnni 
1. There is no aggregation of route information.
2. There is no aggregation of QoS resources. 

It involves grouping of AS (as proposed in QoS routing 
internet draft ) into a PARENT AS. This is HIERARCHICAL 
routing model.

A Connection request can classified into three types.
1. Intra Area Connection requests.
2. Inter Area Connection requests. 
3. Interdomain Connection requests.

A QoS Connection is defined as the "source router" to 
the "destination router". 
Source router : It is the router to which the source 
node is connected. It is upto the link layer 
technoligy to support the QoS from the source node to the 
source router.
Destination Router: It is the router to which 
the destination node is connected. 

So In the proposed hierarchical routing model the end 
systems are the routers connected to the subnets. 

Intra Area QoS Connection Requests:

An area is collection of subnets, routers and hosts. In 
practise the max. number of routers observed are 22.
(Please check it). Each router within a Area maintains 
the complete topology information with QoS parameters. 
Each router maintains a graph of routers within a AREA
with QoS paramaters of links. QOSPF (Check the internet 
draft ) ensures that each participating router has an 
identical QoS database. So whenever there is QoS connection
request the source router can use the EXPLICIT SOURCE 
ROUTE object (refer QoS internet draft ) for the 
route specification in the RSVP PATH message. As all the 
routers within a AREA have the topology database there 
is little probability of connection failure. 

In case of stub areas the STUB ROUTER will take care of all
the connection requests to the outside world. Note that 
stub router need not flood the router toplogy information 
into the stub area. 

Inter Area Connection request :
Every AREA border router will maintain the TOPOLOGY 
INFORMATION OF THE areas. An area can be viewed as 
guarded by area border routers. An area border router 
will flood the CONNECTIVITY information of other ares 
into it's own area. The proposed addressing architecture 
for this case will be shown below. Which simplifies the 
selection algo. of the area border router for a router 
within a AREA. So AREA border router will advertise only
the connectivity to the other border routers with QoS 
parameters. Based on the destination router the originating
router will choose the area border router and the 
EXPLICIT SOURCE ROUTE OBJECT. If the source router 
uses a BAD EXPLICIT SOURCE ROUTE OBJECT then we can 
use CRANK BACK for resolving this issue for ALTERNATE 
ROUTING.

Inter AS QoS Connection Requests:

Bcos of the hierarchical structure this can be of two 
types.
1. A conn. request between two router at same 
hierarchical levels. 
2. A conn. request between two router at different level.
Even though the routing decisions are made 
irrespective of the hierarchical level I have choosen 
these two cases for explanation purpose. 

Peer Group: A set of ASs grouped for purposes of 
a particular peer group.

Peer Group Level: The Level of the peer group 
in the PEER GROUP STACK.

Peer Group Stack: A hierarchical routing as ATM PNNI 
peers. A peer group stack consists of several levels 
and each group level consists "groups of ASs".
Observe that the lowest peer group is a AS. The next 
peer group can be a GROUP OF N ASs.

QoS routing information regarding peer group stack:

Every peer group stack border router will flood 
connectivity information of the peer group as a three 
tuple
< Prefix, Prefix Length, QoS Parameters>.  In the same
the PEER GROUP BORDER ROUTERS WILL flood the QoS topology
information of the neigh. peer group stack into it's own
peer group stack. Observe that the connectivity informatio
is just the reachbility information for the border router.

When ever a BORDER ROUTER ( IT CAN BE A AREA BORDER ROUTE,
PEER GROUP BORDER ROUTE, PEER GROUP LEVEL BORDER ROUTER,
PEER GROUP STACK BORDER ROUTER) receives a EXPLICIT ROUTE
OBJECT IN A RSVP PATH message it will update the SOURCE 
ROUTE OBJECT FROM IT'S own database. 

For this purpose I want to steal a FP from the addr.
architecture and the addre. architecture will be

1. FORMAT PREFIX.
2. TOP LEVEL PEER GROUP STACK IDENTIFIER.
3. PEER GROUP LEVEL IDENTIFIER.
4 & 5 SITE LOCAL IDENTIFIER.
6. Subnet IDENTIFIER.
7. Interface Identifier. 
 
The number of bits in each of these addr. parts is not 
yet decided.

Additional Burden and extensions:
1.BGP should be modified to support the identification 
of hierarchical levels.
2. I want steal one FP from the addr. space.

3. Change of Explicit Source route object in RSVP PATH 
message.
ADVANTAGES:
1. QoS routing can be supported in the INTERNET with
minimal database at the routers. otherwise 
each router has to maintain topology information of the 
internet with QoS parameters. 
2. It supports QoS routing. 

Hope I am clear!!!!
Waiting for your comments
Thanks for your time!!
-Raghu.

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "Raghu V.V.J Vadapalli" <[email-masked]>
Date: Sun, 16 Aug 1998 19:32:26 -0700 (PDT)

Hi!!!!
The main concept is as follows:
The EXPLICIT ROUTE OBJECT will be updated at each 
BORDER ROUTER.( A BORDER ROUTER CAN BE A AREA BORDER ROUTER,
PEER GROUP BORDER ROUTER, PEER GROUP LEVEL BORDER ROUTER,
PEER GROUP STACK BORDER ROUTER ).

The source router will choose the BORDER ROUTER depending
on the PREFIX of the addr. architecture proposed. All the
BORDER ROUTER WILL MAINTAIN the internal topology .

For Example:
An Area border router will maintain internal topology 
of the AREA.
An PEER GROUP BORDER at the lowest level ( i.e., an AS )
border routers will maintain the REACHBILITY INFORMATION
of the AREA  BORDER ROUTERS but not the internal TOPOLOGY
of the AREA. So when a ROUTER in AREA1 wants establish 
a conn. to router in AREA2 it will fill the EXPLICIT 
ROUTE SOURCE OBJECT upto the AREA2 border router. 
The AREA2 border will be choosen based on the prefix of the
DESTINATION. ( The format of the addr. architecture 
allows you to do so.It just like LONGEST PREFIX MATCH 
algo.) So When the AREA2 border router receives the 
EXPLICIT SOURCE ROUTE OBJECT it updates this object 
from it's own database. So the packet will be routed from 
this router based on the UPDATED EXPLICIT SOURCE ROUTE 
OBJECT.

So there is no ON DEMAND PATH COMPUTATION.
Hope I am clear.

Thanks
-Raghu.

> On Sun, 16 Aug 1998, Raghu V.V.J Vadapalli wrote:
> 
> > Dear All..
> > 
> Sounds interesting, can I have a complete version of the proposal?
> I was just wondering how to obtain the QoS information
> for the entire path without aggregation, 
> seems that you are using an on-demand
> path QoS info collection, but that would increase the set up time.
>  
> 
> Guo, Liang
>  
> [email-masked]                   College of Computer Science,
> (617)373-7920 (O)                  161 Cullinane Hall,
> (617)472-5173 (H)                  Northeastern University.
> http://www.ccs.neu.edu/home/guol   MA 02115.
> 
> 
> 
>